Plano de Gestão e Configuração de Software

Histórico de Revisão

Data Versão Descrição Autor(es)
31/08/2019 0.1 Criação do Documento de GCS Rafael
02/09/2019 0.2 Adicionada Introdução e Itens de Configuração Rafael
02/09/2019 0.3 Adicionada Politica de commits Rafael
03/09/2019 0.4 Adicionada Politica de branchs Rafael
05/09/2019 0.5 Adicionados os topicos 4,5 e 6 Rafael
18/11/2019 0.6 Adicionados os topicos 4,5 e 6 Rafael

1. Introdução

Este documento tem como finalidade estabelecer os procedimentos de gerência e configuração de software a serem seguidos no projeto.

2. Itens de Configuração

A preocupação da equipe, referente à configuração, é voltada para a documentação textual e o código. Estes são dispostos conforme o seguinte:

  • Código: Todo e qualquer artefato que seja composto de uma ou mais linguages de programação.

  • Documento: Todo e qualquer artefato textual que contenha informações da matodologia, planejamento, produto, integração da equipe, reuniões e demais informações pertinentes ao processo de desenvolvimento do produto.

3. Políticas

3.1 Política de Commits

  • Os commits devem ser criados logo em seguida à finalização de um conjunto conexo de alterações, descrevendo-o de forma sucinta e atômica. O texto deve descrever o que foi produzido, de forma resumida e em inglês, com o tempo verbal no particípio. Como no seguinte formato:

  • Texto começando com letra maiúscula e com o verbo no particípio.

  • Exemplo:

Updated product logo

  • Commits devem ser redigidos no idioma inglês
  • Devem ser simples e concisos, possuindo títulos curtos
  • Commits devem descrever o que está sendo alterado, se houver mais de uma alteração (pertinente ao commit) ela deve ser adicionada na descrição do commit
  • Devem iniciar com letras maiúsculas.
  • Devem iniciar com um verbo no particípio informando seu objetivo. Ex: "Deleted old files"

3.2 Política de Branches

A política de branches tem o propósito de definir a forma interna de trabalho quanto a organização/implementação de código e ficou definida conforme a imagem a seguir.



  • A Master será a branch principal do projeto em um dado repositório.

  • A Master será a branch estável do projeto e só sera atualizada, a partir da branch development, quando um pull request for aceito. É proíbido que membros subam commits diretamente na Master.

  • A única exceção para essa régra sera no repositório da Wiki.

  • As branches auxiliares são para a resolução das funcionalidades ou correções de erro. Cada Tarefa ou bugfix terá sua própria branch, criada a partir da branch development, e terá como nomenclatura o seguinte padrão:

TF[ID da Tarefa no RoadMap]-[Nome da Tarefa] ou
FIX[ID da issue a ser resolvida]-[Nome da issue] ou
FIX[Nome da correcao ou configuracao] ou
TE-[Nome da Tarefa Extra]

  • Para cada Feature uma nova branch deve ser criada com base no último commit da develop.

3.2.1 Conflitos

  • Se um pull request causar algum tipo de conflito, é deve da equipe responsável pelo pull request resolver o conflito, prezando pela integridade e organização do histórico de commits, e então deve ser refeito o pedido para avaliação do merge.

3.3 Política de Aprovação do Código

  • Para a aprovação do código, este deve ser aprovado por ao menos dois desenvolvedores da equipe diferente daquele que o submeteu ou sua dupla, caso exista.

4. Uso de Issues

  • As issues serão criadas com o objetivo de mapear as histórias de usuário, histórias técnicas e bugs, tendo assim um maior controle sobre eles. Isso facilitará o controle já que o github possui uma plataforma integrada para o acompanhamento de issues.

  • As issues serão divididas em labels com o intuito de facilitar a identificação da sua origem. As labels definidas para o projeto serão:

  • Tarefa: Utilizada para issues que representam features ou atividades do projeto.

  • Tarefa Extra: Utilizada para issues que representam tarefas extras do projeto.
  • Refatoração: Utilizada para issues que representam refatoração do código.
  • Front: Utilizada para issues que representam refatoração do layout.

  • Bug: Utilizada para issues que representam correção de bugs.

  • Caso o time sinta a necessidade de acrescentar uma nova label, este documento deverá ser atualizado.

  • O padrão do nome das issues terá o seguinte formato:

TF <ID da Tarefa no RoadMap> - <Nome definido pela equipe para a tarefa>
FIX - <Nome definido para a história pela equipe>
TE - <Nome definido para a história pela equipe>

  • Exemplo : "TAREFA 1.1 - Tarefa".

5. Repositório de documentação

O repositório de documentação é encontrado na wiki do projeto. O objetivo da Wiki é armazenar toda a documentação criada pela equipe durante o processo de desenvolvimento. Práticas e medidas adotadas serão armazenas no repositório.

6. Referências